feat: Add reusable codeql-analysis-reusable.yml workflow#699
feat: Add reusable codeql-analysis-reusable.yml workflow#699
codeql-analysis-reusable.yml workflow#699Conversation
Adds a reusable CodeQL analysis workflow and refactors `codeql-analysis.yml` to call it instead of running the analysis inline. Centralizing the workflow in `commons-parent` means dependency upgrades (e.g. `codeql-action`) only need to be done once for all repositories. Referencing the `master` branch is safe because the same PMC controls both `commons-parent` and the other `commons-*` repositories.
There was a problem hiding this comment.
Pull request overview
Introduces a reusable CodeQL analysis workflow in this repository and refactors the existing CodeQL workflow to call the reusable one, reducing duplication and making future CodeQL-action upgrades easier to roll out.
Changes:
- Add a new reusable workflow
.github/workflows/codeql-analysis-reusable.ymlthat runs CodeQL in a language matrix and restores Maven cache. - Refactor
.github/workflows/codeql-analysis.ymlto invoke the reusable workflow instead of defining the full job inline. - Add
.github/workflows/README.mddocumenting reusable workflows and the CodeQL reusable workflow usage/permissions.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/codeql-analysis.yml | Switches to calling the reusable CodeQL workflow; sets minimal top-level permissions and job permissions. |
| .github/workflows/codeql-analysis-reusable.yml | Defines the reusable CodeQL workflow with workflow_call input and CodeQL steps. |
| .github/workflows/README.md | Documents how to use the reusable workflows, including CodeQL inputs and required permissions. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
For context: from the discussion we had in November I deduce that:
This means we could upgrade those three workflows more often, but at the same time have the same churn as updating 40 repositories quarterly. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
Please, no. I am not a fan of this style of GitHub usage (see Log4j's impossible to understand for a mere mortal set up). I don't want have to be, or other maintainers to become GHA experts. This usage would force a hierarchical set up for builds at the GHA level, and I see the complexity as outweighing any value. |
Similar to #699, adds a reusable Scorecard analysis workflow and refactors `scorecards-analysis.yml` to call it. Unlike the CodeQL workflow, which only relies on actions from GitHub-owned organisations (`github` and `actions`), this one uses a third-party action (`ossf/scorecard-action`) that needs to be upgraded in a timely manner. The usual process is: 1. A new version of the action is released. 2. The action is reviewed in `infrastructure-actions` and the new SHA is added to the authorized ones. 3. The old SHA is scheduled for removal. We need to perform the upgrade between steps 2 and 3, so we should configure Dependabot to bump this action weekly with a 7-day cooldown (step 2 occurs within 7 days of a new release).
Similar to #699, adds a reusable Scorecard analysis workflow and refactors `scorecards-analysis.yml` to call it. Unlike the CodeQL workflow, which only relies on actions from GitHub-owned organisations (`github` and `actions`), this one uses a third-party action (`ossf/scorecard-action`) that needs to be upgraded in a timely manner. The usual process is: 1. A new version of the action is released. 2. The action is reviewed in `infrastructure-actions` and the new SHA is added to the authorized ones. 3. The old SHA is scheduled for removal. We need to perform the upgrade between steps 2 and 3, so we should configure Dependabot to bump this action weekly with a 7-day cooldown (step 2 occurs within 7 days of a new release).
It has a default value, so it can be optional.
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
|
I hear you on complexity. The goal here isn't to replicate Log4j's setup, just to centralize the three workflows that we never debug: CodeQL, Scorecards, and Dependency Review. The pain points with the status quo:
A reusable workflow for just these three would reduce churn without adding any meaningful cognitive overhead: they're essentially fire-and-forget. Proposal: let's try it scoped to these three only. If debugging ever becomes an issue in a downstream repo, we inline it back. Does that work for you? |
Not true. I've been updating the actions, as you can see the version is current (or should be since I updated them yesterday.) The version checks are quarterly because a person I won't name changed them from This PR makes the build more complex and harder to maintain, so I am against it. |
|
This should be discussed on the mailing list. I am in favour of trying it. I see this change as similar to the use of commons-parent in all derived projects. That is not without problems since each release cycle of a project typically uncovers an issue in commons parent. A fix integrated at the parent then cascades the fix to other projects, with some overhead to ensure the fix works. If this is trialled and the maintenance and frequency of issues increases then we can stop the trial. But we will not know without a trial. |
This means a lot of mechanical work for you, so you have less time to tasks that would actually benefit from your expertise. This is the main reason I hate Dependabot churn.
I fully support that decision for Maven, but we probably didn't discuss it enough for GitHub Actions. These can become deprecated if the GitHub API changes or the Node version they use becomes unsupported, so we have to upgrade them more often. On the other hand if we upgrade carelessly, GitHub Actions and NPM is the heaven of supply-chain attacks. |
|
Since we now have an overview of all the CodeQL workflows across repositories (#701), should I merge this PR and experimentally deploy the workflow across some projects? For example I could start with:
What do you think? |
|
This will happen naturally as I've started a release train of most of these components. If you want to try one, try Collections, the others are in my release train. |
Adds a reusable CodeQL analysis workflow and refactors
codeql-analysis.ymlto call it instead of running the analysis inline.Centralizing the workflow in
commons-parentmeans dependency upgrades (e.g.codeql-action) only need to be done once for all repositories. Referencing themasterbranch is safe because the same PMC controls bothcommons-parentand the othercommons-*repositories.